Various electronic devices, such as mobile telecommunication terminals, portable computers and PDAs require access to security related components such as application programs, cryptographic keys, cryptographic key data material, intermediate cryptographic calculation results, passwords, authentication means for externally downloaded data etc. It is often necessary that these components, and the processing of them, is kept secret within the electronic device. Ideally, they shall be known by as few people as possible. This is due to the fact that a device, for example a mobile terminal, could possibly be tampered with if these components are known. Access to these types of components might aid an attacker with the malicious intent to manipulate a terminal.
Therefore, a secure execution environment is introduced in which environment a processor within the electronic device is able to access the security related components. Access to the secure execution environment, processing in it and exit from it should be carefully controlled. Prior art hardware comprising this secure environment is often enclosed within a tamper resistant packaging. It should not be possible to probe or perform measurements and tests on this type of hardware which could result in the revealing of security related components and the processing of them.
The “Mobile Information Device Profile” for Java™ 2 Micro Edition, Version 2.0, by the JSR 118 Expert Group defines an enhanced architecture and associated application program interfaces (APIs) required to enable an open, third-party, application development environment for mobile information devices (MIDs). Examples of MIDs include cellular phones, two-way pagers, and wireless-enabled PDAs. If a device determines that an MID application can be trusted, then access is allowed as indicated by security policy of the device. Signed applications may become trusted by authenticating the signer of the applications.
The Mobile Information Device Profile provides a mechanism for applications to persistently store data and retrieve it later in so called record stores. A record store consists of a collection of records that will remain persistent across multiple invocations of an application. The mobile information device platform is responsible for making its best effort to maintain the integrity of the record stores of the applications throughout the normal use of the platform, including reboots, battery changes, etc. Record stores are created in platform-dependent locations, which are not exposed to applications.
In the prior art, when performing security related operations in a device accessed by many different parties, the parties accessing the device by means of different application programs, the many different non-coordinated, mutually independent parties each want to manage their own cryptographic data such as cryptographic keys, cryptographic key data material, intermediate cryptographic calculation results and passwords in the device, and this results in a number of different problems. For example, the secure execution environment normally has its designated owner. The secure execution environment can e.g. be provided in the form of a smart card, typically arranged in a mobile telephone. The designated owner of the smart card is the card issuer, and it is the card issuer that decides which application programs are accepted and handled by the card, for example what software that initially is loaded into the card and what types of commands the card complies with. This leads to the problem that the card issuer is given a dominant role as sole card administrator and can prohibit other parties from re-using the smart card for their own purposes. Generally, creation of an object on a smart card, by an application of a party which is not the administrator of the smart card in question, requires the permission of the administrator. This is problematic, since it normally entails on-line connection to a server of the administrating party, i.e. the card issuer. Further, even if the object is established on a card, access control of the object is basically non-existent; either the object is globally available to all applications that can access the card, or it is only available to the applications of the card administrator.